Saltar al contenido principal

Introducción

Si bien no existe una definición concreta y unificada de una credencial verificable, podemos decir que, en el ámbito de la Identidad Auto-soberana, consiste en un documento digital que contiene datos relacionados a una determinada persona o cosa, representando una situación particular del sujeto a que refiere, con el objetivo de probar la veracidad de su contenido ante un sujeto verificador.

Su formato consiste en un Objecto de tipo JSON que contiene indentificadores y metadatos para describir las propiedades de la credencial, como su emisor, período de validez, imagen representativa, una clave pública para usar con proposito de verificación, mecanismos de revocación, entre otras. Los metadatos pueden estar firmados por el emisor, por lo que su autenticidad podrá ser probada mediante una verificación criptográfica.

Ejemplo de Credencial Verificable​

{
  "@context": [
    "https://extrimian.blob.core.windows.net/rskec/person.jsonld",
    "https://w3id.org/security/bbs/v1",
    "https://www.w3.org/2018/credentials/v1"
  ],
  "id": "8b00e43a-c4ec-451d-8b1b-95ae49357df9",
  "type": ["VerifiableCredential", "SecurityCard"],
  "credentialSubject": {
    "type": "Citizen",
    "identifier": "did:quarkid:zksync:EiBgHBYWJuMAWTRCOJpnFVEcQ4r2cPLFK9obk2qBBKMODQ"
  },
  "expirationDate": "2023-07-18T19:00:37.329Z",
  "issuanceDate": "2023-07-17T19:00:37.330Z",
  "issuer": {
    "id": "did:quarkid:zksync:EiAGpo5alPOjRDZr5o1tJsbwxapWLrudxpEJML3cxjSAQQ",
    "name": "MediCare"
  },
  "proof": {
    "type": "BbsBlsSignature2020",
    "created": "2023-07-17T19:00:57Z",
    "proofPurpose": "assertionMethod",
    "proofValue": "pllzhIz4iGjQ9GZyDGuuJWpxjtiv8V7VaaJ28Je7ttM16VHT9kgrTiKy7rfnoghyJmSZEgbMbmoURRP0yJmkF+5Rb6RW7j+exRwVndypfDNB/rZ0lrbolzuxr6bvm7HAznsGewibBG0pA8zdMyiI5g==",
    "verificationMethod": "did:quarkid:zksync:EiAGpo5alPOjRDZr5o1tJsbwxapWLrudxpEJML3cxjSAQQ#vc-bbsbls"
  }
}

Context​

Cuando dos softwares necesitan intercambiar datos, deben utilizar una terminología que ambos comprendan. Por ejemplo, consideremos cómo dos personas se comunican. Ambas personas deben usar el mismo idioma y las palabras que utilizan deben tener el mismo significado para ambas. Esto podría denominarse el contexto de una conversación.

Las credenciales verificables y las presentaciones verificables tienen muchos atributos y valores identificados por URL. Sin embargo, esas URL pueden ser largas y no muy amigables para los humanos. En tales casos, los alias más cortos y amigables pueden ser más útiles. Esta especificación utiliza la propiedad @context para mapear tales alias en forma de abreviaturas a las URL requeridas por credenciales verificables y presentaciones verificables específicas.

Las credenciales verificables y las presentaciones verificables DEBEN incluir una propiedad @context. En el caso particular de QuarkID las URLs proporcionadas en esta sección, deben ser procesables como JSON-LD.

JSON-LD, que significa "JSON Linked Data" (Datos Enlazados en JSON), es una forma de representar datos estructurados utilizando la sintaxis de JSON mientras se incorporan conceptos de Datos Enlazados (Linked Data) para permitir la interoperabilidad semántica en la web.

Imaginemos que tenemos una credencial verificable en formato JSON básico que representa información sobre la afiliación de una persona a una universidad:

{
  "id": "http://university.example/credentials/58473",
  "type": ["VerifiableCredential"],
  "issuer": "did:example:University1",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "name": "John Smith",
    "alumniOf": {
      "name": "University 1"
    }
  },
  "proof": {}
}

En este JSON, puedes ver información sobre la credencial, como el emisor (issuer), la fecha de validez (validFrom), el sujeto de la credencial (credentialSubject), etc.

Ahora, imaginemos que otras instituciones también emiten credenciales verificables, pero pueden usar diferentes terminologías o estructuras en sus datos.

{
  "id": "http://university.example/credentials/58473",
  "type": ["VerifiableCredential"],
  "issuer": "did:example:University2",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "name": "John",
    "lastName": "Smith",
    "alumniOf": {
      "name": "University 2"
    }
  },
  "proof": {}
}

En este caso, la propiedad "name" tiene una interpretación diferente en comparación con la primera universidad. Aquí es donde entra JSON-LD.

Utilizando JSON-LD, podes agregar contexto a tus datos, de manera similar al ejemplo anterior. El mismo JSON anterior se puede expresar en JSON-LD de la siguiente manera:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/58473",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "did:example:University1",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "name": "John Smith",
    "alumniOf": {
      "name": "University 1"
    }
  },
  "proof": {}
}

En este caso, la adición de @context proporciona información sobre el contexto del documento. Las URL proporcionadas en el contexto establecen la base para la interpretación de los términos utilizados en la credencial. Esto ayuda a que diferentes sistemas comprendan y procesen las credenciales de manera consistente, incluso si utilizan terminologías ligeramente diferentes.

Volviendo al ejemplo, gracias al uso de JSON-LD y la especificación del contexto, los verificadores podrán comprender la interpretación específica de cada universidad y ajustar sus procesos en consecuencia.

Este enfoque permite la flexibilidad y la interoperabilidad al manejar diversas interpretaciones de los datos en diferentes contextos, garantizando que los sistemas puedan comprender y verificar credenciales incluso cuando las terminologías varían entre emisores.

Diferencias entre Contexts, Types y CredentialSchemas​

Esta sección tiene como objetivo proporcionar una comparación de las propiedades @context, type y credentialSchema en los modelos de datos de credenciales verificables y presentaciones verificables. También cubre algunos casos de uso más específicos donde es posible utilizar estas características del modelo de datos. La propiedad "type" se utiliza para identificar de manera única el tipo de credencial verificable, indicando qué conjunto de afirmaciones contiene. Es obligatoria y se sugiere incluir un valor adicional que represente el subtipo único de la credencial. Esta propiedad es esencial para especificar la naturaleza de la información contenida en la credencial.

Por otro lado, la propiedad "@context" se usa, desde la perspectiva de JSON-LD, para transmitir el significado de los datos y las definiciones de términos de la credencial de manera legible por máquinas. En una representación JSON, sigue siendo obligatoria y proporciona soporte básico para la semántica global. Mapea URIs únicos globalmente para propiedades en credenciales verificables y presentaciones verificables en nombres más cortos y amigables para los humanos. Esto facilita la lectura de las representaciones tanto en JSON como en JSON-LD.

La propiedad "credentialSchema" tiene como propósito principal definir la estructura de la credencial verificable y los tipos de datos para los valores de cada propiedad. Es útil para especificar el contenido y la estructura de un conjunto de afirmaciones en la credencial. Se utiliza para definir la estructura de la credencial, mientras que "@context" y JSON-LD se centran en transmitir las semánticas y definiciones de términos.

En resumen, "type" se enfoca en identificar el tipo de credencial, "@context" se centra en transmitir el significado de los datos de manera legible por máquinas, y "credentialSchema" se utiliza para definir la estructura y tipos de datos de la credencial. Cuando se combinan "@context" y "credentialSchema", productores y consumidores pueden tener más confianza en el contenido esperado y los tipos de datos de la credencial verificable.

Presentación de una Credencial Verificable​

El hecho de poseer una credencial no te hace sujeto de la misma. Esto se debe a que si bien una credencial verificable hace referencia a las claves del emisor para su verificación, el poseedor de la credencial debe demostrar que es dueño de las claves privadas del DID al cual se le generó dicha credencial, en este último caso la prueba la genera firmando criptograficamente la presentación.

Las presentaciones son datos derivados de una o más credenciales verificables, emitidas por uno o más emisores, que se comparten con un verificador específico. Una presentación verificable es una presentación a prueba de manipulaciones, codificada de tal manera que se puede confiar en la autoría de los datos después de un proceso de verificación criptográfica. Ciertos tipos de presentaciones verificables pueden contener datos que se sintetizan a partir de las credenciales verificables originales, pero que no las contienen (por ejemplo, pruebas de conocimiento cero).

En el gráfico presentado a continuación, se puede observar a grandes rasgos las principales diferencias estructurales entre una credencial verificable y una presentación verificable.

Verifiable Presentation

Ejemplo práctico​